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Prerequisites & Timeline 


Note:Basic rules apply when using the eZ430-RF2500 boards: 


beware of static electricity, don't touch the components directly; 
never disconnect a target board from the USB programmer if still 
plugged into the computer; 

never disconnect a target board from the battery unit with jumper on 
(two leftmost pictures); 

connect as shown on the two rightmost pictures, otherwise you 
destroy the board ! 


For this tutorial, you need: 


an MSP430 eZ430-RF2500 Development Tool kit, i.e. two target 
boards, a USB programmer and a battery unit [footnote]; 

This set of 2 motes is manufactured and sold by Texas Instruments for 
$49 

a computer running Windows, with a free USB port; 

the following freeware (available online): [AR Quick Start, SmartRF 
studio, PuTTY, eZ430-RF2500 Sensor Monitor Demo, cygwin (with 
packets GNUplot and sys), Xming for Windows [footnote]; 

If this software is not installed, refer to the Installation Instructions 
ideally, an oscilloscope like the Tektronix TDS 210 with a 1Ohm 
resistor mounted in an open jumper. 


This tutorial is meant to be completed within 8 hours (one full day or two 
half days): 


e Lab 1. Discover the development environment, run a basic demo (hour 
1). 

Lab 2. Discover the eZ430-RF2500 board and its components (hour 2). 
Lab 3. Simple examples for the MSP430 (hours 3-4). 

Lab 4. Simple examples for the CC2500 (hour 5). 

Lab 5. RF measurements (hours 6-7). 

e Lab 6. Implementing a preamble sampling MAC protocol (hour 8). 

e Lab 7. Running a Complete Wireless Sensor Network (hour 8). 


Note: 

Thanks! 

This Lab was made possible by Prof. Kristofer S.J. Pister from UC 
Berkeley, and by the generous support of Texas Instruments. The author 
would also like to thank the students for their constructive feedback, as 
well as Ferenc Kovak, Kevin Mulligan and Winthrop Williams for their 
logistic support. 


Installation Instructions 


Note:This document details the software which needs to be installed on the 
host computer before taking the tutorial. Depending on the Labs you want 
to take, you only need to install a subset of the 5 tools described below. 


IAR Kickstart 


Note:This is required for all labs. 


TAR is the tool used to program the eZ430-RF2500 boards. The free 
Kickstart version is limited to compiling 4kB of code. 


e Download from http://focus.ti.com/docs/toolsw/folders/print/iar- 
kickstart.html. 
e Install with default parameters. 


TI Sensor Monitor Demo 


Note:This is required for all labs because it installs the drivers enabling 
your computer to talk to the mote. 


Sensor Monitor is demo software which provides a graphical interface to 
the Texas Instruments Sensor Monitor Demo. 


¢ Download from http://www.ti.com/litv/zip/slac139b. 


¢ Follow default installation for Demo Visualizer, Sensor Monitor 
Installer.exe 

e Store the eZ430-RF2500 Wireless Sensor Monitor [AR Source v1.02 
directory on your computer. 


Pul TY 


Note:This is required for all labs. 


PuTTY is used to read from the serial COM port created by the eZ430- 
RF2500 board when connected to the host computer. 


e Create folder C:/Program Files/putty/ 


that folder. 


Xming 


Note:This is only used in Lab 5. 


Xming is a Linux-like X server which enables cygwin script to display 
windows. 


¢ Download from http://www.straightrunning .com/XmingNotes/. 
¢ Follow default install, but choose not to install any SSH client. 


Cygwin 


Note: This is only used in Lab 5. 


Cygwin is a Linux-in-Windows environment, enabling Linux-like script 
execu- tion on a Windows machine. 


Follow default installation. When asked for a Download Site, choose 
http://www. gtlib.gatech. edu [footnote]. 

This is a must as GATech's download site contains the python-numpy 
package we will need. 

When packages are listed, click on the button in the upper right corner 
until obtaining Full. You obtain a list of all installable packages (much 
like programs in Windows), marked with the word Skip when not 
installed, or the version number when installed. 

Using that list, add the following packages. This is done by clicking on 
the work Skip next to the package name. 


python: An interactive object-oriented scripting language 
python-numpy: Python scientific computing module 
gcc-g++: C++ compiler 

gnuplot: A command-line driven interactive function plotting 
utility 
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Click next several times to finish the installation. 


The Python gnuplot extension enables us to visualize data output by the 
mote connected to the computer. To install it: 


Open cygwin 

unzip that file and | place folder gnuplot -py-1.8/ within inside 
folder C: /cygwin/ 

open cygwin 

type the following lines 


0 cd /cygdrive/c/cygwin/ 


o PYEhOn Setupr py wnistalkl 


e openC:/cygwin/lib/python2.5/site- 
packages/Gnuplot/gp_cygwin. py with WordPad 

e change line default term = 'windows' todefault term 
= 'x11' 

e change line gnuplot command = 'pgnuplot.exe' to 
gnuplot command = 'gnuplot.exe' 


Start Menu Shortcuts 


Note:While not strictly necessary, creating Start Menu shortcuts will make 
your life easier. 


¢ Create a folder eZwsn in the Start Menu folder (typically 
C:/Documents and Settings/All Users/Start 
Menu/) 

e in that folder, create shortcuts to the following programs: 


PuTTY 

IAR Embedded Workbench 
XLaunch (part of Xming) 
cygwin 

eZ430-RF2500 Sensor Monitor 
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Source Code and Resources 


If you take this lab 


When taking the labs contained in this collection, you will be asked to 
create project in IAR, import drivers and copy-paste source code from these 
web pages. As an alternative, and for your convenience, you can download 
the full source code used in this Lab in IAR format: 


e Full IAR source code 


If you are an intructor 


This tutorial has been given as a lab for undergraduate and graduate 
students, using the following documents. You are free to use these 
documents for instructional use, provided you mention the original authors 
name. 


To increase the quality of the contents, we greatly appreciate feedback and 
comments. 


e Lab instructions in pdf format. These contain the same information as 
this tutorial, but the students are asked to answer a few questions and 
to fill out the initially empty result tables. 

e Exam questions regarding this lab (multiple choice). 


1.1. eZ430-RF2500 Sensor Monitor Demo 


Note:The eZ430-RF2500 board comes with demo software, which creates 
a WSN in a star topology around the Access Point. A node which is not an 
access point is called an End Device. By running this demo, you will learn 
how to use the IAR tool. 


Running the Code 


e Locate the folder containing the source code of the Sensor Monitor 
Demo, which was created when you followed the installation 
instructions [footnote]. 

Alternatively, this code is available in the downloadable source code, 
in the ti_demo folder. 

¢ Double-click on €Z430-RF2500 Sensor Monitor Demo 
v1.02 .eww, this opens IAR. 

e In the Workspace, select the Overview tab, right click on the End 
Device project and choose Set as Active. 

e Plug in the USB programmer, and select Project > debug 
(Ctrl+D). The source is compiled, downloaded onto the target board 
and a default breakpoint causes execution to stop at function main(). 
Stop the debug session by selecting Debug > Stop Debugging 
(Ctrl+Shift+D); 

e Disconnect the USB programmer and swap the target boards between 
the USB programmer and the battery unit. 

e In Workspace, set the ACcCeSsS Point project as active. Repeat the 
programming process. You now have two programmed target boards; 
close IAR. 


Running the Demo 


e Plug in the Access Point target board mounted on the USB 
programmer in the computer. Both LEDs start blinking. 


e Launch Start Menu > ezwsn > eZ430-RF2500 Sensor 
Monitor, displaying the temperature of the Access Point. 

e You see the temperature of the access point. Switch on your end 
Device, which appears on the screen 
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You're one when you have a similar window 
on your screen. 


1.2. Oscilloscope: Read the Current Consumption 


Note:The End Device is instructed to transmit a message every second; its 
radio is off the remainder of the time. Using the oscilloscope together with 
the 1-Ohm resistor, you will be able to visualize the current consumption 
of the board. 


e Leave the Access Point plugged into the computer. 
e Switch the target board on using the jumper with the 1-Ohm resistor: 


Use the 1-Ohm jumper to 
switch on the target board. 


¢ Connect the oscilloscope onto the resistor as in the following figure. 
What you read is the current consumption in amps of the board (U = 
RI, with R = 1). 


Read the current 


consumption of the board. 


e You should read energy consumptions close to the following Figure. 
There are fourmain phases: the radio is switched on (A), IDLE mode 
(B), RX mode (C) and TX mode (D). 
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You're done when you see a screen similar to this one 
on your oscilloscope. 


e We can assume the boards are powered by two AAA batteries with a 
capacity of 1000 mA*hr, under the hypothetical condition in which the 
batteries hold their voltage ideally until their capacity is exhausted. 
The following Table can be used to calculate the approximate lifetime, 
using the previous measurements: Average current consumption is 
0.700mA; Lifetime with a 1000mA*hr battery is about 2 months. 


Phase duration av. current 


sleep 995.34ms 0.600mA 
radio is switched on 0.360ms 4.80mA 
IDLE mode 0.780ms 13.6mA 
RX mode 2.680ms 24,.2mA 
TX mode 0.840ms 26.0mA 


Duration and average current consumption of the different phases 
observed. 


1.3. Read Directly From COM Port 


Note:So far, the SensorMonitor visualizer has extracted the data the access 
point node and displayed it graphically. In this section, you will read the 
data coming from the access point directly from the COM port, i.e. you’ ll 
have access to the raw data. You will learn how to use PuTTY and 
Windows’ Device Manager. 


¢ Close all open windows; plug in the access point board. 

e Open the windows Device manager (Vista: Start, Settings, 
Control Panel, Device Manager; XP: Start, 
Settings, Control Panel, Computer Management, 
Device Manager). 

e UnderPorts (COM and LPT), you'll see a device called MSP430 
Application UART (COMx), remember that number x; 

e Open PuTTY, select Connection Type: Serial and enter the correct 
COM«x in Serial Line, leave Speed at 9600, click Open 


e You obtain a screen close to the following: 
[ coma - PuTTY Sox) 


You're done when you see a screen similar to this one. 


2.1. Crash Course on the MSP430f2274 


Note:So far, you have played around with existing code and have had a 
high level view of the mote. It is now time to dig into the hardware and 
understand both what the mote board is composed of, and how you can 
program it. This section is purely theoretical (i.e. no exercises), but serves 
are a basis for the subsequent sections in which you will have to write 
software for the board. 


The heart of this platform is its MSP430 microcontroller, by Texas 
Instruments. There is a complete family of MSP430 micro-controllers, the 
variants of which are different in the amount of RAM/ROM and I/O 
capabilities, mainly. The one you will program is the MSP420f2274, 
featuring 32KB + 256B of Flash Memory (ROM) and 1KB of RAM. 


The MSP430 is a 16-bit RISC microcontroller. 16-bit means that all 
registers hold 16 bits; interconnection between the elements of the micro- 
controller is done using 16-bit buses. RISC — for Reduced Instruction Set 
Computer — refers to the fact that there are (only) 27 core instructions. 


Operation of the MSP430 


The following figures shows the internal architecture of the MSP430. The 
CPU contains 16 registers; its operation goes as follows. A system clock 
ticks at a programmable rate (e.g. 1MHz), so each ps an instruction is 
fetched from memory (ROM), copied into the right register and executed. 
An example execution can be adding two registers and copying the result to 
a third. In practice, these low-level details are taken care of by the compiler, 
which translates C into assembler language and binary code. In this tutorial, 
we only work with the higher-level C. 
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The internal architecture of the MSP430. 


Programming the MSP430 


When you program a mote, you program its microcontroller, i.e. you put the 
compiled binary code at the right location in the MSP430's ROM memory. 
When the board is switched on, the MSP430 starts by fetching the first 
instruction at a predetermined location in ROM; this is where the 
programming tool puts your compiled code. 


To configure other components (e.g. to set the transmission power of the 
radio), you need to program the MSP430 in such a way that it configures 
the radio at the beginning of your program. 


Interrupts 


A program for a wireless mote is in practice a sequence of very small pieces 
of codes executed when some event happens: e.g. when the button is 
pressed, turn on the red LED. When an event happens in an electronic 
element outside the MSP430 (e.g. the button is pressed), this element 


informs the MSP430 by changing the electric state of the wire which 
connects this element to the MSP430. This wire is connected to one of the 
ports of the MSP430 (e.g. port P1. 2 in the case of the button on the eZ430- 
RF2500). You need to program the MSP430 in such a way that changing 
the status on port P1.2 generates an interrupt. When an interrupt is 
generated, theMSP430 stops its current execution (if any), and starts 
executing a specific function called the Interrupt Service Routine (ISR) 
associated to that particular interrupt. Once this function is finished 
(normally an ISR is a very small function), it resumes its normal execution 


(if any). 


You will write ISRs in to response when pushing the button (3.3), timer 
interrupts (3.4) and when receiving a packet at the radio (4.2). 


Timers 


When writing code, you may want to wait some time before doing 
something (e.g. when I receive a packet, wait 10ms, and send a reply 
packet). This can be done using a timer, a specific component of the 
MSP430. Physically, a timer is a 16-bit register which is incremented at 
each clock cycle, i.e. once every ps with a 1MHz clock. It starts at 0, and 
counts up until a programmable value, upon which is generates a timer 
interrupt, reset to 0, and starts counting up again. 


You will use timer in section to have a LED flash at a given rate (3.4). 


I/O Functionalities 
The MSP430 has 40 pins: 


e 4 have analog functions to power the board; 

e 2 are used for testing at the factory; 

e 2 are used if an external crystal is used as clock source, which is not 
the case on the eZ430-RF2500 platform; 

e 32 have digital functions. 


The 32 digital pins are grouped into 4 ports of 8 pins each. Each pin has a 
name in the form Px. y, y represents the position of the pins within port x. 
All pins can be generic I/O pins, a number of 8-bit registers are used to 
configure them: 


e PXDIR.y sets the direction of port PXDIR. y; output if PXxDIR. y=1, 
input if PXDIR. y=0; 

e PXOUT .Yy sets the state of port PX. y when set as output; 

e PXIN.y reads the state of port PX . y when set as input; 

e PXIE.y enables interrupts on that port; 


Each of these registers hold 8 bits, one for each pin. As a result, 
P1iDIR=0b11110000[footnote] means that pins P1.0 through P1.3 are 
input, while P1.4 through P1. 7 are outputs. To set/reset a specific pin, 
you need to use the binary operators presented in the following code: 

Obx means that x is written in binary; 0Xx means that x is written in 
hexadecimal. We thus have 0X1A=0b00011010. Use Windows 
Calculator in Scientific mode for quick conversions. 


Assuming A = 

Q©b01101001, we have: 

~A = 0b10010110 

A |= 0b00000010: A=0b01101011 

A & ~0b00001000: A=0b01100001 

A A= 0b10001000: A=0b11100001 

A << 2: A=0b10100100 

A >> 2: A=0b00011010Binary operators used to 
set/reset individual 

bits. 


Note that most of the 32 digital pins can also be used for specific functions 
(SPI interface, input for Analog-to-Digital conversion, ...), see the 
MSP430x22x2, MSP430x22x4 Mixed Signal Microcontroller datasheet for 
details. 


Low-Power Operation 


As the MSP430 spends its time waiting for interrupts, it is important to 
reduce its energy consumption during idle periods by shutting down the 
clocks you are not using. The more clocks you shut down, the less energy 
you use, but make sure you leave on the clocks you need. There are four 
low power modes (LPM1, ..., LPM4) which shut down different clocks 
(details in the MSP430x2xx Family User's Guide). 


In practice, you only need to leave on the auxiliary clock which clocks a 
timer to wake the MSP430 after some time. This is achieved by entering 
low-power mode 3, by adding this line at the end of your main function: 


__bis_SR_register(LPM3_bits); 


Note: You now know enough about the MSP430 for this tutorial, but if you 
want to work with the MSP430, you are strongly advised to read the 
MSP430x2xx Family User's Guide and the MSP430x22x2, MSP430x22x4 
Mixed Signal Microcontroller datasheet (in that order). 


2.2. Crash Course on the CC2500 


The CC2500 is the radio chip on the eZ430-RF2500. It functions in the 
2400- 2483.5 MHz frequency band and provides an excellent option for 
WSN applications because of its low-power characteristics. This chip has 
20 pins: 


e 2 for connecting a (mandatory) 26MHz external crystal oscillator; 

e 2 for connecting the antenna; 

e 10 for powering the chip; 

¢ 6 for digital communication with the MSP430 (to be detailed in section 
g.0) 


The chip contains 47 registers to configure operating frequency,modulation 
scheme, baud rate, transmission power, etc. Because these registers are 
erased during power down, the MSP430 should configure all of them at 
startup. 13 commands allow the MSP430 to control the state of the CC2500 
(transmit, power down, receive, .. . ). The CC2500 follows a state diagram, 
as detailed in the CC2500, Low-Cost Low-Power 2.4 GHz RF Transceiver 
datasheet. 


In practice, Texas Instruments provides some code which hides the low- 
level details of the CC2500 behind a higher level API. These drivers are 
part of the SimpliciTI project, available for free. We will use these off-the- 
shelf drivers in this tutorial. 


Note: You now know enough about the CC2500 for this tutorial, but if you 
want to work with the CC2500, you are strongly advised to read the 
CC2500, Low-Cost Low-Power 2.4 GHz RF Transceiver datasheet (after 
having read the documents about the MSP430). 


2.3. The eZ430-RF2500 Board 


Overview 


The following figure shows the different components on the eZ430- 
RF2500. In particular, some of pins of the MSP430 are exported as 
extension pins P1 through P18. Note that some of these pins may be 
unused pins of the MSP430, others are already used, but duplicated as 
extension ports for debugging purposes. 
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The components of the eZ430- 
RF2500. 


Interconnecting the MSP430 with the CC2500 


As show in the following figure, 6 wires interconnect the MSP430 (micro- 
controller) with the CC2500 (radio). 4 of them form the SPI link, a serial 
link which enables digital communication. There is a hardware SPI modem 
on each side of the link, the configuration of which is handled by the 
drivers. 
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MSP430 and CC2500 are interconnected by an SPI 4-wire 
link (plain) and two interrupt lines (dotted). 


The remaining two links are wires used by the CC2500 to wake-up the 
MSP430. That is, the MSP430 configures its ports P2.6 and P2. 7 as 
input, with interrupts. It then configures the CC2500 to trigger GDOO or 
GDO2 on a given event (typically, when receiving a packet). This enables 
the MSP430 to enter LPM3. Note that these wires are also routed to 
extension port pins P13 and P14. The drivers are used in such a way that 
only GDOO is used for proper operation. You can thus configure GDO2 as 


you wish, and monitor its state with an oscilloscope on extension port pin 
P14. 


Refer to the eZ430-RF2500 Development Tool User's Guide for details 
about the eZ430-RF2500 platform. 


3.1. A Steady LED 


Creating a Project in IAR 


If you want to create your own project in IAR, you need to repeat these 
steps: 


e¢ Connect the eZ430-RF2500 programming board to the computer and 
open IAR; 

e Choose Create new project in current workspace; 

e Leave Tool Chain to MSP430; as project template, choose C > 
main; click OK; 

e Create a directory on your desktop in which you save your project; 

e GotoProject > Option (Alt+F7), in General Option, choose 
Device=MSP430F2274; in Debugger, choose Dr lver=FET 
Debugger. 


For your convenience, you can download the entire source code for the labs 
in this collection, organized in IAR projects. Open 
source_code/iar_v4.11.lab_eZwsn. eww and browse through 
the different projects in the Workspace panel on the left. 


Running the Code 


e Copy the following code into IAR [footnote]. 
Alternatively, this code is available in the downloadable source code. 
Open source_code/iar_v4.11/lab_ezwsn. eww with IAR. 
The project corresponding to this section is called led_steady. 

¢ Compile and download the code onto the board (Ctrl+D). 

e Let the code execute (F5), you should now see both LEDs on. 


#include "10430.h" 
int main( void ) 


WDTCTL = WDTPW + WDTHOLD; 
P1DIR |= 0x03; 


P10UT |= 0x03; 
while(1); 
}Switching on both LEDs 


Some keys for understanding the code: 


Line 1: 10430. h contains all the macros used for translating human 
readable values (e.g. PLDIR) into actual memory location. Right click 
on 10430.h and choose Open "10430.h" to see its content. 
Line 4: The MSP430 has a watchdog timer which resets the board if it 
is not reset before it elapses. This way, if you code hangs, the board 
restarts and continues functioning. For our simple examples, we 
disactivate this function by writing the correct values into register 
WDTCTL. 

Line 5 declares P1.0 and P1.1 as output pins. This is done by 
turning bits 0 and 1 to 1 in register PLDIR; 

Line 6 sets the output state of pins P1.0 and P1. 1 to logic 1 
(physically somewhere between 2.2V an 3.5V). This causes the LEDs, 
connected to those pins, to light. 

Line 7 loops, leaving the board running. 


Energy Consumption 


Comment out line 6 and run the board from the battery unit. Use the 
resistor jumper and the oscilloscope to read out the default energy 
consumption (i.e. MSP430 running, no LEDs, no CC2500); 

Repeat this by leaving line 6. By subtracting the results, you can 
measure the energy consumption of the LEDs; 

replace line 6 by PLOUT |= OxO1andP10UT |= 0x02 will 
leave on the red and green LEDs only, respectively. You can now 
measure the consumption of the LEDs independently. 


Make sure you obtain results close to the ones presented in the following 
table. 


no IEDs (MSP430 running) 3.12mA 


red+green LED 9.12-3.12=6.00mA 
red LED 7.04-3.12=3.92mA 
green LED 5.20-3.12=2.08mA 


Current consumed by the LEDs 


3.2. Active Waiting Loop 


Note:This example shows a first way of measuring time. 
__no_operation( ) 


instructs the MSP430 to do nothing during one cycle; by repeating this 
many times, time can be measured. As this is neither accurate nor energy- 
efficient, a more elegant technique will be shown in section 3.4. 


Running the Code 


¢ Copy the code presented below [footnote]. 
Alternatively, this code is available in the downloadable source code. 
Open source_code/iar_v4.11/lab_ezwsn. eww with IAR. 
The project corresponding to this section is called Led_loop. 

e Compile and download the code onto the board (Ctrl+D). 

e Let the code execute (F5), both LEDs should blink. 


#include "10430.h" 
#include "1n430.h" 
int main( void ) 


{ 
WDTCTL = WDTPW + WDTHOLD; 
int 1; 
P1DIR |= 0x03; 
while (1) { 


P10UT “= 0x03; 
for (1=0;1<10000;1i++) { 
__no_operation(); 


} 


}Blinking LEDS using an active waiting loop 


Some keys for understanding the code: 


e Line 9: the operator “= causes 1s to become Os and vice-versa (aka 
toggling).In case of our LEDs, it causes their on/off state to change; 
¢ Line 10:__ no_operation( ); causes the MSP430 to do nothing 

for one cycle. 


Measuring Time 


We want to measure time precisely with the oscilloscope. This can, in 
theory, be done by measuring the voltage at the LEDs, but it is hard to hold 
the probes right. We will therefore use extension pin P6 represented in the 
figure below, which is connected to P2.3 on the MSP430. 
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The extension pins on the eZ430- 
RF2500 board. Note that the pins 
with even number (shown on the 
right) are located on the edge of the 
board, and are thus accessible more 
easily. 


We will configure P2 .3 to be output and toggle its state together with the 
state of the LEDs. Therefore: 


e addline P2DIR |= 0x08; after line 7 to declare P2.3 as output; 


e addline P2OUT “= 0x08; after line 9 to toggle P2. 3 after toggling 
the LEDs; 

¢ connect a probe of your oscilloscope to extension port P6, ground on 
extension port P12; 

¢ power on the board, you're now able to read the duration between two 
toggles; 

e reprogram your board with waiting values between 1000 and 30000; 
verify that the times obtained are close to the ones presented the 
following table. 


threshold value for 


measured toggle duration 


1 

1000 6.72ms 
10000 67.2ms 
20000 134.0ms 
30000 201.0ms 


Duration when using an active waiting loop 


3.3. Button-Driven Toggle Through Interrupts 


Note:The goal of this section is to start using interrupts through the button 
on the board. You will program the board so that the LEDs change state 
when the button is pressed. You will also measure the energy consumed 
when the board sits idle, and when it enters a low-power mode. 


Running the Code 


¢ Copy the code presented in the following listing [footnote]. 
Alternatively, this code is available in the downloadable source code. 
Open source_code/iar_v4.11/lab_ezwsn. eww with IAR. 
The project corresponding to this section is called Led_button. 

e Compile and download the code onto the board (Ctrl+D). 

e Let the code execute (F5), press the button on the board, the LEDs' 
state should change. 


#include "10430.h" 
#include "in430.h" 
int main( void ) 
id 
WDTCTL = WDTPW + WDTHOLD; 
P1DIR |= 0x03; 
P1DIR & ~0x04; 
P1REN |= 0x04; 
P1IE |= 0x04; 
__bis_SR_register(GIE); 
while(1); 
Z 
#pragma vector=PORT1_VECTOR 
__interrupt void Port_1 (void) 
{ 
P1IFG &§= ~0x04; 


P10UT “= 0x03; 
}Toggle LEDs state using the button 


Some keys for understanding the code: 


Lines 6 and 7 declare P1.0 and P1.1 as outputs (for the LEDs), and 
P1.2 as input (for the button); 

Line 8 activates an internal resistor on P1. 2. This is needed for a 
button for the signal to be cleaner when the button is pressed; i.e. 
otherwise, the P1.2 constantly floats between high and low state. This 
is only needed for buttons. 

Line 9 enables interrupts on P1. 2. 

Line 10 enables interrupts globally. 

Line 13 and 14 declare that this function should be called when an 
interrupt of type PORT1_VECTOR happens; the name Por t_1 chosen 
has no importance. 

Line 16 resets the interrupt flag generated (mandatory otherwise the 
function will be called again right after it finishes execution). 


Low-Power Modes 


As such, the board sits idle while waiting for an interrupt to happen with the 
MSP430 on (which continuously executed line 11). After measuring this 
current, you will change the code so as to enter low-power mode instead of 
sitting idle. 


Using the battery unit, the resistor jumper and the oscilloscope, 
measure the current consumed in this mode (make sure that the LEDs 
are off when you measure). 

Change line 10 by__bis_SR_register(GIE+LPMO_bits);. 
This instructs the MSP430 to enable the interrupts globally, and to 
enter LPMO mode immediately. Only an interrupt can wake the 
MSP430. 

Remove line 11 which can never be reached. 

Measure the current now, make sure that LEDs are again off. 

repeat with LPM3 and LPM4. 


You should obtain results close to: 


Active mode (active: CPU and all clock) 3.28mA 
LPMO mode (active: SMCLK, ACLK; disabled: CPU, 2. 88mA 
MCLK) ; 
LPM3 mode (active: ACLK; disabled: CPU, MCLK, 2.72mA 
SMCLK) ; 
LPM4 mode (disabled: CPU and all clock) 2.72mA 


Current consumed by the LPM modes 


Note that, because we are not using any clock in this example, we should 
use LPM4 as it is the most energy-efficient. 


3.4. Timer-Driven Toggle Through Timer Interrupts 


Note:We will explore a energy-efficient way of measuring time by using 
timers. A timer is a register which counts up to a certain number at each 
clock tick. During this, the MSP430 can switch to a low-power mode. Each 
time the timer threshold is reached, a timer interrupt wakes the MSP430, 
which toggles the two LEDs. 


Running the Code 


¢ Copy the code presented below [footnote]. 
Alternatively, this code is available in the downloadable source code. 
Open source_code/iar_v4.11/lab_ezZwsn. eww with IAR. 
The project corresponding to this section is called Led_timer. 

e Compile and download the code onto the board (Ctrl+D). 

e Let the code execute (F5), both LEDs should blink. 


#include "10430.h" 
#include "in430.h" 
int main( void ) 
i 
WDTCTL WDTPW + WDTHOLD; 
P1DIR | 0x03; 
BCSCTL3 |= LFXT1S_2; 
TACCTLO = CCIE; 
TACCRO = 1000; 
TACTL = MC_1+TASSEL_1; 
__bis_ SR_register(GIE+LPM3_ bits); 
7 
#pragma vector=TIMERAO_VECTOR 
__interrupt void Timer_A (void) 
{ 
P10UT “= 0x03; 
}Blink LEDS using timer interrupts 


Some keys for understanding the code: 


Line 7 switches on the ACLK by sourcing it to the VLO, a very low 
power crystal oscillator inside the MSP430, different from the more 
accurate and energy hungry DCO (Digitally Controlled Oscillator). 
The DCO drives the MCLK and the VLO the ACLK. ACLK is used 
for the timer; MCLK for executing code. When there is no code to be 
executed (i.e. when waiting for interrupts), a low power mode (in 
which DCO is switched off) can be used. 

Line 8 enables interrupts for Timer_A. 

Line 9 sets the value up to which Timer_A will count. 

Line 10 tells Timer_A to count up (MC_11) each time ACLK ticks 
(TASSEL_1). 

Line 11 enables interrupts globally and enters LPM3. Note that LPM3 
leave only ACLK running, which is exactly what we need because our 
Time_Aruns off ACLK. 


Measuring Time 


We use extension pin P6 to measure time exactly. Therefore: 


add line P2DIR |= 0x08; after line 6 to declare P2.3 as output; 
add line PZOUT “= ©x08; after line 16 to toggle P2.3 after 
toggling the LEDs; 

connect a probe of your oscilloscope to extension port P6, ground on 
extension port P1. Power on the board, you're now able to read the 
duration between two toggles. 

reprogram your board with TACCR®O values between 1000 and 30000; 
verify that the times obtained are close to the following: 


TACCRO value measured toggle duration 


500 47.40ms 


1000 95.00ms 
10000 950.0ms 
20000 1890ms 


Duration when using timers 


This table informs you that 1000 ACLK cycles take 95.00ms, one ACLK 
cycle thus takes 95us, the VLO on the MSP430 thus runs at 10.5kHz. In 
theory, the VLO runs at 12kHz; the exact value depends on the voltage of 
the batteries and on the temperature. 


4.1. Using the Texas Instruments Drivers 


Texas Instruments has developed a set of drivers for the eZ430-RF2500 as 
part of the simpliciTI project, freely available online. You will use them 
without changing the files. 


If you want to create your own project, you need to take the following steps 
to include the drivers: 


e In JAR, create a new project as instructed in Section 3.1. 

e GotoProject > Options (Alt+F7), then to C/C++ compiler. In 
the Preprocessor tab, add the following lines in the 
Additional include directories text field. This tells IAR 
to look into these folders when you include files in your source 
code.S6PROJ_DIR$\..\drivers\bsp 
$PROJ_DIR$\..\drivers\bsp\drivers 
$PROJ_DIR$\..\drivers\bsp\boards\EZ430RF 
$PROJ_DIRS$\. .\drivers\mrfi 

e Inthe defined symbols text field, add the following line. This 
tells the drivers you have a CC2500 radio chip on your board. 
MREI_CC2500 

e in the Workspace panel, right click on the name of your project, and 
use Add, Add Group... to make the following group structure 
(where groups bsp and mr fi are inside group Components): 
Application Components - bsp - mrfi Output 

e useAdd, Add Files... toadd files bSp.c, bsp.h and 
bsp_macros.h under group bsp. Similarly, add files mrfi.c, 
mrfi.h andmrfi_defs.h under group mr fi. Add your C code as 
a file under group Application. 


For your convenience, you can download the entire source code for the labs 
in this collection, organized in IAR projects. Open 
source_code/iar_v4.11.lab_ezwsn. eww and browse through 
the different projects in the Workspace panel on the left. 


4.2. Simple Tx/Rx 


Note: This first example involves two boards which stay in Rx mode by 
default. When you press a button on either one, it sends a message and 
toggles its green LED; the board which receives the message toggles its red 
LED. Once this is functional, you will play with the Rx/Tx frequency. 


Running the Code 


e Copy the code presented below [footnote]. 
Alternatively, this code is available in the downloadable source code. 
Open source_code/iar_v4.11/lab_ezwsn. eww with IAR. 
The project corresponding to this section is called txrx_simple. 

e¢ Compile and download the code onto both boards (Ctrl+D). 

e Switch both boards on (one with the battery unit, the other with the 
USB slot of your PC); when you press one's button, the other's red 
LED should toggle. 


#include "mrfi.h" 
#include "radios/familyi/mrfi_spi.h" 
int main(void) 
{ 
BSP_Init(); 
P1REN |= 0x04; 
P1IE |= 0x04; 
MRFI_Init(); 
MRFI_WakeUp(); 
MRFI_RxOn(); 
__bis_ SR_register(GIE+LPM4 bits); 


void MRFI_RxCompleteISR() 


{ 
P10UT A= 0x02: 


} 


#pragma vector=PORT1_VECTOR 
__interrupt void Port_1 (void) 
1 
P1IFG &§= ~0x04; 
mrfiPacket_t packet; 
packet. frame[0]=8+20; 
MRFI_Transmit(&packet, MRFI_TX_TYPE_FORCED); 
PAOUT A= 0x01; 
}The simplest Tx/Rx example possible 


The packet format is: 


Length Source Destination Payload (Length-8 
(1B) (4B) (4B) bytes long) 


packet.frame 


RSSI (1B) CRC (1b) LQI (1b) 
packet.rxMetrics 
A variable of type mr fiPacket_t is a structure containing two parts: 


e packet.frame is the frame to be transmitted. The first byte is the 
Length of the payload together with source and destination Address. 
With the current driver implementation, addresses are coded on 4 
bytes, and the maximum Payload length is 20 bytes. By default, the 


CC2500 does not perform address filtering, so in practice we will not 
care about the values of the address fields. 

e packet.rxMetrics are statistics on the last received packet, i.e. it 
only makes sense on received packet. The first byte is the Received 
Signal Strength Indicator (RSSI) at sync word detection. This is the 
signal level in dBm. The next bit indicates whether the Cyclic 
Redundancy Check (CRC) was successful (by default, the CC2500 is 
configured to reject packets with unsuccessful CRC check, so in 
practice this field will always be 1). The last 7 bits are the Link Quality 
Indicator (LQT). The LQI gives an estimate of how easily a received 
signal can be demodulated by accumulating the magnitude of the error 
between ideal constellations and the received signal over the 64 
symbols immediately following the sync word. 


Some keys for understanding the code: 


e Line 4 is a function from the drivers (right-click on it, and choose GO 
to definition of "BSP_Init()" if you want to know) 
which disables the watchdog, initializes the MCLK at 8MHz, sets LED 
ports as outputs and the button port as input. Note that it does neither 
enables the internal resistor of the button, nor enables interrupts. This 
is done on lines 5 and 6. 

e Line 7. MRFI stands for Minimal Radio-Frequency Interface; 
functions starting with MRFI are used to drive the CC2500 radio chip. 
MRFI_Init( ) initializes the 6 wires between the MSP430 and the 
CC2500, powers-up the CC2500 and configures the CC2500 47 
registers and turns on interrupts from the CC2500; 

e Line 8 wakes up the radio, i.e. it turns on the 26MHz crystal attach to 
it without entering Rx or Tx mode; 

e Line 9 switches the radio to Rx mode; from this line on, it can receive 
packets, in which case the interrupt function 
MRFI_RxCompleteISR is called [footnote]. 

Note that the real interrupt function with the usual #pragma 
declaration is hidden in the drivers 


Choosing a Frequency 


The CC2500 can transmit at any frequency on the ISM band 2400.0-2483.5 
MHz. The chip divides the 2400.0-2483.5 MHz spectrum into channels 
separated by a tunable channel spacing. By default, channel spacing is 
200kHz; with default configuration, channel 0 is 2433.0Mhz, channel 1 is 
2433.2Mhz, and so forth. The channel is configured through the CHANNR 
register of the CC2500. 


e add 1 the following line at the very top of the code. This way, you have 
access to low level driver functions which enable you to write directly 
the CC2500 registers: #include 
“radios/familyi/ mri osoi sn 

e add the following line right after MRFI_Init();. You may replace 
©x10 by the frequency you have chosen. This programs the CHANNR 
register of the CC2500. Be aware that values above OXFC are 
prohibited because the corresponding frequency is above 2483.5 MHz: 
mrfiSpiWriteReg(CHANNR, 0x10); 


When you have reprogrammed both boards, you should be able to 
communicate without interference. 


4.3. Continuous Tx/Rx 


Note:We abandon the push button, and ask one board to sent messages 
continuously, while the other receives. Once this constant flow of data is 
established, you will be able to see the energy consumption of the 
transmitting and receiving boards, for a number of settings of transmission 
power. 


Running the Code 


e Start from the code used in 4.2. Simple Tx/Rx. 

e Replace line PLIFG &= ~0x04; byP1IFG |= 0x04;. This 
means that once you push the button, the board will start sending an 
infinite number of messages. This is because you force the interrupt 
flag to remain active, i.e. when your code leave the Interrupt Service 
Routine, it immediately re-enters because, according to the interrupt 
flag, there is still and interrupt pending. 

e Reprogram both boards, switch them on, and push one button. 


Energy Consumption 


e You may wish to command out lines PLOUT “= 0x02; and P1OUT 
A= ©xXO1; so that your LEDs remain off not to measure their energy 
consumption; 

e Use the oscilloscope to measure the energy consumption; 

e Make sure you obtain results which are close to the following figures. 
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Energy consumption with continuous Tx/Rx. 


Note:As you can see, the radio accounts for most of the energy consumed 
by the mote. Additionally, as a rule of thumb you may safely consider that 
transmitting, receiving and idle listening cost about the same energy. 


Impact of Transmission Power 


We want to measure the impact of the transmission power on the current 
consumption of the board. Therefore: 


e if not there yet, add the following line at the beginning of your file: 
#include "radios/familyi/mrfi_spi.h" 

e right after line MRFI_Init();, add 
mrfiSpiwriteReg(PATABLE, OxFF) ;. This programs the 
PATABLE register of the CC2500, which is responsible for the 
transmission power of the radio. You can put any value between 0x00 
and OXFF;, which is then mapped to a transmission power as shown 
in the next table. 


e Use your oscilloscope to visualize the maximum energy consumed. 
Repeat this for different values of PATABLE. Check that you have 


results close to the ones presented in the next figure. 


register 
0x84 
0x55 
0x97 
OxA9 
OxFE 


OxFF 


power 


-24dBm 


-16dBm 


-10dBm 


-4dBm 


0dBm 


1dBm 


Impact of transmission power on current 


current 


16.1mA 


16.5mA 


18.3mA 


22.6mA 


27.6mA 


27.9mA 


Gurrent (mA) 


Impact of transmission power on current 


Note: Varying the transmission power from -20dBm to OdBm (i.e. 200 
times more power) only doubles the motes current consumption. This is 
because the electronics account for the largest amount of energy: at OdBm, 
1mW is sent over the antenna, while the mote consumes 
27.6mMA*3V=82.8mW. 


4.4. Wireless Chat 


Note:Now that you can send packets between nodes, you will put content 
into those packets. Data is entered through the keyboard and sent over the 
air when pressing enter. The receiver prints the received data on the screen. 
You are thus building a wireless chat program. 


Note:Because you want to type to and read from both motes, you need to 
have two USB programmers. 


Running the Code 


e Copy the code presented below [footnote]. 
Alternatively, this code is available in the downloadable source code. 
Open source_code/iar_v4.11/lab_ezwsn. eww with IAR. 
The project corresponding to this section is called txrx_chat. 

e¢ Compile and download the code onto both boards (Ctrl+D). 

e Connect each board to a computer using the USB programmer and 
open PuTTY. Type something and hit enter, the message should appear 
on the other side's screen. 


#include "radios/familyi/mrfi_spi.h" 
#include "mrfi.h" 
uint8_t index_output = 9; 
mrfiPacket_t packetToSend; 
int main(void) 
{ 

BSP_Init(); 

MRFI_Init(); 

P3SEL |= 0x30; // P3.4,5 = USCI_AO 
TXD/RXD 

UCAOCTL1 = UCSSEL_2; // SMCLK 


UCAOBRO = 0x41; // 9600 from 8Mhz 

UCAOBR1 = 0x3; 

UCAOMCTL = UCBRS_2; 

UCAOCTL1 &= ~UCSWRST; // Initialize USCI state 
machine 

IE2 |= UCAORXIE; // Enable USCI_AO RX 
interrupt 


MRFI_WakeUp()j; 

MRFI_RxOn(); 

index_output=0; 

__bis_ SR_register(GIE+LPM4 bits); 


void MRFI_RxCompleteISR() 
{ . . 
uints_t 1; 
PAOUT A= 0x02; 
mrfiPacket_t packet; 
MRFI_Receive(&packet ); 
char output[] = {" iat a 
for (1=9;1<29;i++) { 
output[1-9]=packet.frame[i]; 
if (packet.frame[i]=='\r') { 
output[1i-9]='\n'; 
output[1i-8]='\r'; 
} 
} 
TXString(output, (sizeof output)); 
} 
#pragma vector=USCIABORX_VECTOR 
__interrupt void USCIORX_ISR(void) 
{ 
char rx = UCAORXBUF; 
uint8_t 1; 
packetToSend.frame[index_output ]=rx; 
index_output++; 
if (rx=='\r' || index_output==29) { 
packetToSend.frame[0]=28; 


MRFI_Transmit(&packetToSend, 
MRFI_TX_TYPE_FORCED); 
index_output = 9; 
for(1=9;1<29;1i++) { 
packetToSend.frame[i]J=' '; 


P1OUT “= 0x01; 
is 
P10UT A= 0x02; 
TXString(&rx, 1); 


I 
Some keys for understanding the code: 


e Lines 9-15 configure the UART module used to communicate over the 
serial port. In particular, line 17 enables interrupts for incoming traffic, 
i.e. when you write onto PuTTY. 

e Lines 21-36. Function MRFI_RxCompleteISR is called when a packet 
is received. The red LED is switched on (Line 26), and an empty 
output string is modified with the received characters before being 
sent. 

e Lines 37-55. Function USCIORX_ISR is called when you enter a 
character on PuTTY. This 8-bit character is stored at the right byte in 
the outgoing packet (line 45). When you hit enter or you have type 29 
consecutive characters (44), the frame is sent and the output buffer is 
initialized for subsequent text. 


Note:If you have multiple motes and multiple computers, all messages 
typed on one computer will appear on all screen. To reduce the broadcast 
group, you may wish to switch to another frequency channel using the 
code described in 4.2. Simple Tx/Rx. 


5.1. The importance of CRC 


Note:Each packet is appended with a 16-bit Cyclic-Redundancy- Check 
(CRC) which is used to detect accidental alterations of data during 
transmission. CRC is computed over the data portion of the frame. Upon 
receiving a packet, the CC2500 recomputes a CRC over the received data 
and compares that values with the received CRC. A mismatch indicates a 
corrupted packet; by default, the CC2500 silently drops such a packet. You 
will disable CRC and see how often corrupted packets occur. 


Running the Code 


e Copy code presented below [footnote]. 

Alternatively, this code is available in the downloadable source code. 
Open source_code/iar_v4.11/lab_ezwsn. eww with IAR. 
The project corresponding to this section is called tXrx_crc. 

e¢ Compile and download the code onto both boards (Ctrl+D). 

e Connect one board to a computer using the USB programmer, and read 
its output using PuT TY. 

e Power the other with the battery packet and press the button. You 
should read ‘abcdefghijklmnopqrstu' on PuTTY. 

e Repeat his multiple times by moving away the sending node; you 
should see some alterations to the output text. If CRC was enabled, 
these packet would have been dropped by the CC2500 and you 
wouldn't see them on the screen. 

e You may wish to speed things up by changing PLIFG &= ~0x04; 
toP1IFG |= 0x04; on the sender's side so one press of the button 
generates an infinite stream of packets. Similarly, you may wish to 
reduce its transmission power as explained in 4.3. Continuous Tx/Rx. 


#include "radios/familyi/mrfi_spi.h" 
#include "mrfi.h" 

mrfiPacket_t packetToSend; 

int main(void) 


BSP_Init(); 

P1REN |= 0x04; 

PL1IE |= 0x04; 

MRFI_Init(); 
mrfiSpiwriteReg(PATABLE, ©xBB); 
mrfiSpiwriteReg(PKTCTRLO, 0x41); 


P3SEL |= 0x30; 
UCAOCTL1 = UCSSEL_2; 
UCA@BRO = 0x41; 
UCAOBR1 = 0x3; 
UCAOMCTL = UCBRS_2; 


UCAOCTL1 &= ~UCSWRST; 
MRFI_WakeUp(); 

MRFI_RxOn(); 

__bis_ SR_register(GIE+LPM4 bits); 


void MRFI_RxCompleteISR() 


{ 


uint8_t 1; 

P10UT A= 0x02; 
mrfiPacket_t packet; 
MRFI_Receive(&packet); 
char output[] = {" 


\r\n"}; 


} 


for (1=9;1i<packet.frame[0];i++) { 
output[i-9]=packet.frame[i]; 


TXString(output, (sizeof output)); 


#pragma vector=PORT1_VECTOR 


{ 


interrupt void Port_1 (void) 


P1IFG &§= ~0x04; 
char character = ‘'a'; 
uint8_t index; 
mrfiPacket_t packet; 


for (index=9; index<30;indext++) { 
packet. frame[ index ]=character++; 
t 


packet. frame[0]=++index; 
MRFI_Transmit(&packet, MRFI_TX_TYPE_FORCED); 
P10UT A= 0x01; 


5.2. Creating a Spectrum Analyzer to Measure Noise 


Note:The CC2500 can easily change its operating frequency, through the 
use of channels. For each of these channels, the CC2500 can sense the 
level of electro-magnetic noise, in dBm. The goal of this section is to build 
a spectrum analyzer by continuously plotting noise vs. frequency. We 
therefore use a Python script running on the host computer. 


Note:For this section, you will need to have installed all the software. If 
not, please follow the Installation Instructions. 


Running the Code 


Copy-paste the code presented below into IAR [footnote], and 
program a single board; close IAR. 

Alternatively, this code is available in the downloadable source code. 
Open source_code/iar_v4.11/lab_ezwsn. eww with IAR. 
The project corresponding to this section is called txrx_noise. 
Copy-paste the python code below into a new file called 
txrx_noise. py in some directory on your computer [footnote]. 
Alternatively, this file is already present in the downloadable source 
code, in the directory source_code/c_files/. 

Connect your USB programmer board to the host computer, and find 
the COMx port it is connected to. Use PuTTY to read from that x port; 
you should see a continuous series of 200 numbers appearing. 

Start an X server onto the host computer using XLaunch you have 
installed on your computer. 

Start Cygwin and go into the folder containing ./txrx_noise.py 
using commandcd path to your folder [footnote]. 

In cygwin, your Windows drive C:\ is called /cygdrive/c. Also, 
use forward slashes. If your folder is located at 


C:\Users\Thomas\Desktop\source_code, in Cygwin, type 
cd /c/cygdrive/Users/Thomas/Desktop/source_code. 

° typeexport DISPLAY=127.0.0.1:0.0 

¢ type cat /dev/comx. You should see the same content appearing 
as when using PuTTY. If not, read the COMxport with PuTTY and try 
again. 

e typecat /dev/comx | ./txrx_noise.py A window appears 
which looks like the one depicted below. 


#include "mrfi.h" 
#include "radios/familyi/mrfi_spi.h" 
void print_rssi(int8_t rssi) 
{ 
char output[] = {" 000 "}; 
if (rssi<0) {output[O]='-';rssi=-rssi;} 
output[1] = '0'+((rssi/100)%10); 
output[2] 'O'+((rssi/10)%10) ; 
output[3] 'O'+ (rssi%10); 
TXString(output, (sizeof output)-1); 
} 
int main(void) 
{ 
int8_t rss1; 
uint8_t channel; 
BSP_Init(); 
MRFI_Init(); 


P3SEL |= 0x30; 
UCAOCTL1L = UCSSEL_2; 
UCA@BRO = 0x41; 
UCAOBR1 = 0x3; 
UCAOMCTL = UCBRS_2; 


UCAOCTL1 &= ~UCSWRST; 
MRFI_WakeUp(); 
__bis_SR_register(GIE); 
while(1) { 
for (channel=0; channel<200;channel++) { 
MRFI_RxIdle(); 


mrfiSpiwriteReg(CHANNR, channel); 
MRFI_RxOn(); 

rSSi=MRFI_Rssi(); 
print_rssi(rssi); 


t 
TXString("\n",1); 
I 


} 
void MRFI_RxCompleteISR( ) 
{ 
} 


C code 


#!/usr/bin/env python 
import re, Gnuplot, sys 
if _name__ == '__main__': 
print 'display started...' 
g = Gnuplot.Gnuplot (debug=1 ) 
g('set term x11 title "eZWSN sprectum 
analyzer"' ) 
g('set yrange [-110:0]') 
g('set data style linespoints' ) 
g.xlabel( 'frequency (MHz)') 
g.ylabel( 'RSSI (dBm)' ) 
char = ''! 
line = ''' 
while 1: 
char = sys.stdin.read(1) 
if char == '\n': 
Sline = line.split() 
data = [] 
for 1 in range(len(sline) ): 
try: 
sline[i] = int(sline[1i]) 
except: 
Sline[i] = 0 
frequency = 2433.0+(0.2*1) 


data.append([frequency, sline[i]]) 
g.plot(data) 
line = ''' 
else: 
line = line + charPython code 


xX eZWSN sprectum analyzer 
U 


RSSI (dBw) 


2457.21, 41,44935 
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B02.11b/g ch.? 82,1ib/g ch.3 802.11b/9 ch,11 
ch.6 802,11b/g ch,8 802,11b/g ch,10 


Output of the spectrum analyzer in Section 6.2; one 


transmission is going on on channel 0. 


Some keys for understanding the code running on the mote: 


e Line 6. print_rssi() isa function which prints the RSSI value 


read from the CC2500 onto the serial port which is initialized between 
lines 18 and 25. TXString() is a function provided in 
bsp_board.c. 

Lines 18-25 initialize the serial port, which enable your code to output 
lines of text using the TXString( ) function. These lines can then be 
read using PuTTY. 

Line 27 instructs the MSP430 to stay in active mode all the time, i.e. 
not to enter any low power mode. 

Lines 28-37 is a loop which continuously scans through channels 0- 
200, recording and outputting the RSSI value. MRFI_Rssi() isa 
function declared in the drivers. 


The python script continuously feeds the GNUplot environment with data 
received from the standard interface. Note that the content of the right 
COM«x port if piped to this python script. 


Refresh Rate of the Spectrum Analyzer 


e inthe code, after line BSP_Init();, addline P2DIR |= 0x08; 
e in the code, after line TXString("\n",1);, addline P2DIR “= 
0x08,. This toggles extension port P6 every time the screen gets 

refreshed. 

e using the oscilloscope, measure on extension port P6 the refresh rate 
of the frequency analyzer. Make sure to refresh rate is around 1.1s. 

e move line P2DIR “= 0x08; right after line 
print_rssi(rssi);. You now measure the time it takes for the 
mote to sample the noise level on one channel, and move to the other. 

e Make sure you measure a value close to 5.5ms. 


Testing the Spectrum Analyzer 


e Reprogram a second board using the code described in 4.3. Continuous 
Tx/Rx, so that it continuously sends data. Start the continuous sending 
and visualize this transmission on the spectrum analyzer (at channel 0 
by default). 

e Using the technique described in 4.2. Simple Tx/Rx, change the 
operating channel, and see the implications on the spectrum analyzer. 

e You can also see the impact of a running microwave oven. 


Note:When you bring the transmitting mode close to the receiver, you see 
on the spectrum analyzer that the signal ‘leaks' over multiple channels. This 
is why a standard such as IEEE802.15.4 specifies the channel spacing to be 
SMHz. We have set the spacing to a much lower value (200kHz) on 
purpose to see the effect of adjacent channel leakage. In practice, you 
should use frequencies which are far away from each other. 


5.3. RSSI vs. Distance 


Note: You will draw the RSSI received as a function of distance between 
sender and receiver. Because of the random nature of propagation, 
especially in a closed room, you will see that this relationship is not 
straightforword to predict. It should be clear that repeating these 
measurements under different conditions yields very different results. 


Note:For this section, you will need to have installed all the software. If 
not, please follow the Installation Instructions. 


You will modify the code for the mote taken from 5.2. Creating a Spectrum 
Analyzer to Measure Noise in order to read 200 times the RSSI value from 
the same channel. A python script will then average those read values. To 
this end: 


e Use the code from 5.2. Creating a Spectrum Analyzer to Measure 
Noise, but comment out line 
mrfiSpiwriteReg(CHANNR, channel) ;. The mote will now 
read the RSSI 200 times on channel 0. 

e Reprogram the receiver board and visualize the values outputted on the 
COM<x port using PuTTY (see 1.3. Read directly from COM Port). We 
are interested in calculating the average value of each 200 point line. 

e Copy-paste the code presented below to a new file called 
txrx_rssi_dist. py [footnote]; 

Alternatively, this file is already present in the downloadable source 
code, in the directory source_code/c_files/. 

e in Cygwin, run the python script cat /dev/comx | 
./txrx_rssi_dist.py [footnote]. This script outputs the average 
value of the RSSI 200 readings. 

In Cygwin, you should first go to the folder containing 
txrx_rssi_dist.py, see 5.2. Creating a Spectrum Analyzer to 


Measure Noise. 

e Reprogram a second board using the code described in 4.3. Continuous 
Tx/Rx, so that it continuously sends data, on channel 0 and with a 
transmission power of 0dBm. 

e Start the continuous sending and see how the RSSI decreases as the 
transmitter is moved away from the receiver. 


#!/usr/bin/env python 
import sys 


if _name__ == '__main__': 
Char = '! 
line ='' 
while 1: 
char = sys.stdin.read(1) 
if char == '\n': 


Sline = line.split() 
sumsum = 0 

counter = 0 

for 1 in range(len(sline) ): 


try: 
Sline[i] = int(sline[1i]) 
sumsum += sline[i] 
counter += 1 

except: 


Sline[i] = 0 
result = sumsum/counter 
print result 
line = '! 

else: 
line = line + char 


The figure below plots the evolution of RSSI as transmitter and receiver 
boards are parted away in three different directions. Because these 
measurements are not done in an infinite open space, shadowing and fading 
effects introduce randomness into the relationship between RSSI and 
distance. 
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Evolution of RSSI with distance. 


Note:RSSI can not be predicted knowing the distance. This means that you 
can not know for sure two nodes are able to communicate by just the 


distance to one another. Similarly, distance can not be predicted knowing 
the RSSI. 


5.4. Channel Success Probability 


Note: You have seen that the strength of a link can not be easily predicted 
as a function of the distance between sender and receiver, especially 
indoors. You will now discover the relationship between the RSSI of a link 
and its probability. We define link probability as the portion of the 
messages sent by the sender which are successfully received at the 
receiver. You will see that link probability is strongly correlated to the 
RSSI. 


The experimental setup goes as follows. You will use to boards, a sender 
and a receiver. The sender continuously sends bursts of 100 messages, each 
containing a counter which increases from 1 to 100. Out of those 100 sent 
messages, the receiver may only receive 40. It will count the number of 
received messages until the counter reaches 100, or until the counter loops 
back to a smaller value. When this happens, the receiver outputs the number 
of received messages, i.e. the probability of the link. 


At the same time as the receiver counts the number of the received 
messages, it calculates the average RSSI over those 100 messages, which it 
outputs together with the link probability. Finally, to allow for the receiver 
to output these statistics (which takes some time), after each burst of 100 
messages, the sender sends 20 messages with counter set to 101. 


To implement this: 


e Reprogram two boards with the code taken from the listing below 
[footnote]. 
Alternatively, this code is available in the downloadable source code. 
Open source_code/iar_v4.11/lab_ezwsn. eww with IAR. 
The project corresponding to this section is called 
EXr xX Goda b ila ry. 

e Attach one board to the host computer, and read the output from 
COM«x using PuTTY; 


Power the second board from the battery unit and press the button; this 
will cause that board to transmit the bursts of 100 messages. You can 
read the statistics using PuTTY. 

Reprogram the sender node by changing line P1IFG &= ~0x04; by 
P1IFG |= 0©x04;. This causes a continuous stream of messages. 
Power the newly programmed node on the battery pack and press the 
button; the red LED flashes. 

On the receiver side, verify with PuTTY that you are receiving 
continuously. Close PuTTY. 

Open Cygwin, and enter cat /dev/comx > 
probability.txt. This logs the output in a file. 

Walk away with either node to record data for low RSSI values. Press 
(Ctrl+C) in Cygwin to stop the logging process. 

Start XLaunch. In Cygwin, type export 

DESPEAY=127, 00.1700. 

In Cygwin, enter gnuplot, thenplot "probability. txt" 
uSing 1:2. This plots the probability as a function of the RSSI, 
make sure to obtain a graph similar to the one in the figure below. 


#include "mrfi.h" 

uint8_t counter, num_received, bool_counting; 
inti16_t cumulative_rssi; 

mrfiPacket_t packet; 

void print_probability(inti6_t cumulative_rssi, 
uint8_t number ) 


{ 


char output[] = {" 000 0.00\n"}; 
if (cumulative_rssi<O) { 


output[O]='-'; 
cumulative_rssi=-cumulative_rssi; 


} 

output[1] = '0'+((cumulative_rssi/100)%10) ; 
output[2] = '0'+((cumulative_rssi/10)%10) ; 
output[3] = 'O'+ (cumulative_rssi%10); 
output[5] = 'O'+((number/100)%10); 
output[7] = '0'+((number/10)%10) ; 

output[8] = 'O'+ (number%10); 


TXString(output, (sizeof output)-1); 


int main(void) 

{ 
BSP_Init(); 
P1REN |= 0x04; 


P1IE |= 0x04; 
MRFI_Init(); 

P3SEL |= 0x30; 
UCAOCTL1 = UCSSEL_2; 
UCA@BRO = 0x41; 
UCAOBR1 = 0x3; 
UCAOMCTL = UCBRS_2; 


UCAOCTL1 &= ~UCSWRST; 
MRFI_WakeUp()j; 
MRFI_RxOn(); 
__bis_ SR_register(GIE+LPM4 bits); 
} 
void MRFI_RxCompleteISR() 
‘ 
P10UT A= 0x02; 
MRFI_Receive(&packet) ; 
counter = packet.frame[9]; 
if (counter==101) { 
if (bool_counting == 1) { 


print_probability(cumulative_rssi/num_received, num 
_received); 

} 

bool _counting=0; 

num_received=0; 

cumulative_rssi=0; 

} else { 
bool_counting=1; 
num_received++; 


cumulative_rssi+=Mrfi_CalculateRssi(packet.rxMetri 


cs[0]); 
} 


} 
#pragma vector=PORT1_VECTOR 


__interrupt void interrupt_button (void) 
t 
P1IFG &= ~0x04; 
P10UT A= 0x01; 
mrfiPacket_t packet; 
packet. frame[0]=8+3; 
for (counter=1; counter<101; counter++) { 
packet.frame[9]=counter; 
MRFI_Transmit(&packet, MRFI_TX_TYPE_FORCED); 


for (counter=0; counter<20;counter++) { 
packet. frame[9]|=101; 
MRFI_Transmit(&packet, MRFI_TX_TYPE_FORCED) ; 
} 
} 


Some keys to understand the code: 


e Line 55. When the button is pressed, the board continuously sends 
bursts of 100 messages followed by 20 "guard" messages. 

¢ Line 61. The format of a packet is presented in 4.2. Simple Tx/Rx. 
packet.frame|[0] is the length field, which sets the payload 
length at 3 bytes (minimum accepted value). 

e Line 63. packet. frame| 9] is the first byte of the payload. 

e Line 43. bool_counting indicates whether the statistics have 
already been printed out (without this semaphore, as there are 20 guard 
messages, the statistics would be printed out 20 times) 


As shown in hte figure below, link probability is closely correlated to RSSI. 
The theory tells us that, at very low RSSI, link probability is very close to 0; 
at very high RSSI it is close to 1. Between those extremes, there is a linear 
slope, shown as an overlay in the figure below. 
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6.1. An Introduction to Preamble Sampling 


Note:Preamble-sampling is a technique used to reduce the energy 
consumption of the MAC protocol in a wireless node. The goal of this 
section is to measure the energy consumption of the transmitting and 
receiving nodes, and to predict the lifetime of a node when powered on two 
AAA/LRO3 batteries. 


Nodes using preamble-sampling are not synchronized. Instead, nodes 
periodically listen for a very short time (called Clear-Channel-Assessment, 
or CCA) to decide whether a transmission is ongoing. We call check 
interval (CI) the amount of time a node waits between two successive 
CCAs. The sender needs to make sure the receiver node is awake before 
sending data; it prepends a (long) preamble to its data. By having the 
preamble at least as long as the wake-up period, the sender is certain that 
the receiver will hear it and be awake for receiving the data. 


The figure below is a chronograph depicting the radio state of node S and 
its three neighbors A, B and C. A box above/under a vertical line means the 
node's radio is transmitting/ receiving, respectively. No box means the radio 


is off. All nodes sample the channel for Dcca seconds every CI seconds. 
preamble data 


Daca Disa 


Basic preamble-sampling. 


In this Section, you will implement a simplified version of preamble 
sampling: 


e there is no data; 

e the preamble is cut into a series of micro-frames. Each micro-frame 
contains a counter indicating how many micro-frames still remain. A 
micro-frame is sent every Tmf seconds, and lasts for Dmf. 


6.2. Running the code 


The experimental setting goes as follows. You will have two boards, both 
sampling periodically sampling the channel. When they are not sampling 
the channel, the CC2500 is switched off and the MSP enters low-power 
mode. When you press a button on one board, it sends a preamble cut into 
50 micro-frames; the receiver hears a micro-frame and keeps listening until 
it hears the last one. 


To this end: 


e Program two board with the code taken from listing below [footnote]; 
one will be the transmitter, the other the receiver. 
Alternatively, this code is available in the downloadable source code. 
Open source_code/iar_v4.11/lab_ezwsn. eww with IAR. 
The project corresponding to this section is called 
txrx_preamble_msp. 

e Plug in one of the board into the computer and use PuTTY to read 
from its COMx port; this will be the receiver. 

e press on the transmitter's button, you should read 03 02 O41 n your 
screen. 


#include "mrfi.h" 
#include "radios/familyi/mrfi_spi.h" 
void start_slow_timeout( ) 
{ 
TACTL|=TACLR; TACCTLO=CCIE; TACTL=TASSEL_1+MC_1; 
} 


void stop_slow_timeout() 


{ 
TACTL=MC_0; TACCTLO=0; 


void start_fast_timeout() 


{ 
TBCTL|=TBCLR; TBCCTLO=CCIE; TBCTL=TBSSEL_2+MC_1; 


i 


void stop_fast_timeout() 


TBCTL=MC_0; TBCCTLO=0,; 


} 
void print_counter(int8_t counter) 
{ 

char output[] = {" we 2 


output[O] = 'O'+((counter/10)%10); 
output[1] = 'O'+ (counter%10); 
TXString(output, (sizeof output)-1); 
} 
int main(void) 
4 
BSP_Init(); 
P1IREN |= 0x04; 
PIIE |= 0x04; 
MRFI_Init(); 


P3SEL |= 0x30; // P3.4,5 = USCI_AO 
TXD/RXD 

UCAOCTL1 = UCSSEL_2; // SMCLK 

UCAOBRO = 0x41; // 9600 from 8Mhz 

UCAOBR1 = 0x3; 

UCAOMCTL = UCBRS_2; 


UCAOCTL1 &= ~UCSWRST; // Initialize USCI state 
machine 

IE2 |= UCAORXIE; // Enable USCI_AO RX 
interrupt 

BCSCTL3 |= LFXT1S_2; TACTL=MC_0; TACCTLO=0; 
TACCRO=1060; //slow timeout 

TBCTL=MC_0; TBCCTLO=0; TBCCRO=31781; 
//fast timeout 

start_slow_timeout(); 

__bis_SR_register(GIE+LPM3_bits); 


void MRFI_RxCompleteISR() 


{ 
mrfiPacket_t packet; 


stop_fast_timeout(); 


stop_slow_timeout(); 
MRFI_Receive(&packet); 
if (packet.frame[9]|<4) { 
print_counter(packet.frame[9]); 
start_slow_timeout(); 
} else { 
MRFI_WakeUp(); 
MRFI_RxOn(); 


} 


} 
#pragma vector=PORT1_VECTOR 


__interrupt void interrupt_button (void) 
{ 
P1IFG &= ~0x04; 
Uuint8_t counter; 
mrfiPacket_t packet; 
packet.frame[0]=8+20; 
MRFI_WakeUp()j; 
for (counter=50;counter>=1;counter--) { 
packet.frame[9]=counter; 
MRFI_Transmit(&packet, MRFI_TX_TYPE_FORCED); 


} 


} 
#pragma vector=TIMERAQ_VECTOR 


__interrupt void interrupt_slow_timeout (void) 
{ 
MRFI_WakeUp()j; 
MRFI_RxOn(); 
start_fast_timeout(); 
__bic_SR_register_on_exit(SCG1+SCGO) ; 
} 
#pragma vector=TIMERBO_VECTOR 
__interrupt void interrupt_fast_timeout (void) 
{ 
stop_fast_timeout(); 
MRFI_Sleep(); 


} 


bis _SR_register_on_exit(LPM3_bits); 


Some keys for understanding the code: 


The microcontroller handles two timeouts, one for measuring CI, the 
other for Deca. Those timeouts are sourced by two different clocks: a 
fast and accurate clock for Dcca; a slower, less accurate but extremely 
energy-efficient clock for CI. The fast clock is the Digitally Controlled 
Oscillator (DCO on Timer A) while the very-low-power, low- 
frequency oscillator (VLO on Timer B) is the slow clock. Because CI 
is triggered by the slow clock, that clock stays on all the time. Only 
when the slow timeout expires does the microcontroller start the fast 
clock to clock the fast timeout (DCCa); and stops it when that expires. 
The radio is on only during Dcca. 

Line 38 initializes the slow timeout on Timer A 

Line 39 initializes the slow timeout on Timer B 

Line 42. Because the slow clock runs all the time, the board can only 
enter LPM3 which leaves the VLO clock running. 

Line 71. Every time the slow timeout triggers, the CC2500 is switched 
on in Rx mode (lines 74-75); the fast timeout is started (line 76), and 
because it is clocked by the DCO, LPMO mode is entered which leaves 
the DCO running (line 77). 

Line 79. When the fast timeout expires, this timeout is stopped (line 
82), the CC2500 is put to sleep (line 83) and the LPM3 mode is 
resumed (line 84). 

Line 58. When the button is pressed, the board transmits 50 micro- 
frames, each containing a decrementing counter. 


6.3. Timing issues: length of the preamble 


e Use the oscilloscope to visualize the energy consumed by a board, you 
can clearly see the periodic wakeup of the CC2500 (see figure below, 
lower part). 
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Energy consumed by the transmitter and the 
receiver in preamble sampling. To function, the 
length of the preamble needs to be larger than the 
check interval CI. 


e You can see that the time between two successive wake-ups is 
CI=104ms. Push the button and capture the energy consumed when 
the board is in transmit mode (see figure, upper part). You can see the 
series on 50 microframes sent. 

e By zooming in, you can see that one micro-frame is sent every 
Dcca=3.24ms. Hence, the length of the whole preamble is 
50*3.24=162ms, which is larger that the check interval. 


6.4. Timing issues: first micro-frame heard 


Because the receiver periodically samples the channel, the micro-frame of a 
preamble it hears first can be any of the 50. You will now visualize which 
micro-frame is heard first. To this end: 


e move line print_counter(packet.frame[9]); up two lines 
(right after MRFI_Receive(&packet );_), so that the counter 
value gets printed for every microframe received; 

e after reprogramming a board, connect it to the host computer and read 
its COMx port with PuTTY; 

e press on the second boards button, you should now read a series of 
decrementing numbers such as: 30 29 28 25 24 23 20 19 18 
15 14 13 10 09 08 05 04 O03 [footnote] The first 
number you read is the first micro-frame received (here 30), which is 
not necessarily the first one sent (here 50). 

The sequence may not be continuous because the board spends some 
time writing on its serial port, and thus misses a few micro-frames. 


6.5. Measuring the Energy Consumption 


e Use the oscilloscope to visualize the current drawn by a receiver 
board. 

¢ Zoom in onto a wake-up period and use the averaging function on your 
oscilloscope (on the TDS2022B press acquire, average) to average 
Over as many samples as possible. 

e Freeze the screen once this is done, you should obtain a screen close to 


the following one: 


Current Consumption (mA) 


Energy consumption measured when sampling 
the channel. 


e You easily see the different phases when the CC2500 is turned on, the 
current drawn during these phases and their length (see Table below). 

e As shown in the following table, you can calculate the average current 
consumption of the board when it is listening, and the expected 
lifetime. 


Phase duration 


idle 99.6ms 
A microcontroller startup 0.396ms 
B radio frequency calibration 0.772ms 
C reception mode 3.24ms 
D entering sleep mode 0.032ms 


av. Current 


0.788mA 


5.45mA 


9.55mA 


18.3mA 


5.00mA 


Duration and average current consumption of the different phases 
observed in the figure. Measurements averaged over 128 samples. 


e One can calculate that the average average current consumption is 
1.450mA, hence an expected lifetime of about one month on 


1000mAh. 


Note:By carefully tuning the value of 
CI 
and 


Decca 


(which was not done here for simplicity), the energy consumption of a 
preamble-sampling MAC protocol can be brought down below .1%. 


7.1. Communication Stack 


Note:The source code is too long to be put on this web page. You will have 
to download it. Open 


source_code/iar_v4.11/lab_ezwsn. eww 
with IAR. The project corresponding to this section is called 


txrx_wsn 


Project txrxX_Wsn is a complete WSN example which implements a 
complete communication stack for WSNs, using gradient multi-hop routing. 
A gradient routing protocol assigns a scalar value to each node, which we 
call its height. Heights are assigned in such a way that they increase with 
distance to a central node. Distance is calculated using a cumulative cost 
function based here on hop count. The forwarding process selects the next 
hop as the neighbor which offers the largest gradient, i.e.the neighbor with 
lowest height. 


In the implemented protocol stack, the application layer generates sensed 
data to be sent to a sink node, by using on-board Analog-to-Digital 
Conversion. The routing layer is responsible for updating the node's 
myHeight; the MAC layer performs on-demand neighbor discovery and 
uses preamble sampling for energy-efficiency. 


The execution timeline of the implemented protocol is presented in the 
figure below, for an example topology of 3 nodes. By default, nodes 
perform preamble sampling. When a node wants to send a message (here 
A), it starts by sending a preamble as long as the check interval (CTI) to 
make sure all neighbors hear that preamble. For efficient handling by a 
packet radio, the preamble is cut into a series of micro-frames UF, each 


containing a counter indicating the number of UF still to come. Upon 
hearing a UF, a receiving node turns its radio off and sets a timer to switch 
into receive mode after the last UF. At that moment, the sender indicates the 
duration of the neighbor announcement window to follow in a CW packet. 
data exchange 


: routing decision 


preamble sampling preamble sampling 


! 
! 


packet formats 


Timeline illustrating the execution of the protocol stack. The x-axis 
represents time; a box above the line indicates that the radio is 
transmitting; a gray/white box under the axes means that the radio in 
receiving/idle listening, resp.; no box means the radio is turned off. 


Receivers choose a random backoff for sending an ACK message inside the 
neighbor announcement window and sleep the rest of the time; the sender 
listens for the complete announcement window and populates the initially 
empty neighbor table as it receives ACK messages. 


After the neighbor announcement window, the sender updates its 
myHeight by the minimum value of its neighbors’, incremented by one, 
and select its neighbor with smallest Height. It inserts this information 
into the DATA packet header which it transmits. The destination node 
receives the whole packet while the non-destination neighbor switches to 
sleep after the header. The destination replies with a final acknowledgment 
FIN; all nodes resume preamble sampling. 


7.2. Run a Multi-Hop WSN 


The source code is contained in project txrx_wsn [footnote]. By default, 
each node transmits every 5+rand(5) seconds at -16dBm, on channel 
©. The sink node prints the content of the received packets. 

This code is available in the downloadable source code. Open 
source_code/iar_v4.11/lab_ezwsn. eww with IAR. The project 
corresponding to this section is called txrx_wsn. 


Project txrxX_WSn can not be compiled with the free edition of IAR 
because code size it larger than 4kB. Projects txrx_wsSn_node and 
txrxX_wsn_sink contain already compiled binary code for nodes and 
sink, respectively [footnote]. 

If you have a full edition of IAR, you can use project tx x_wsn directly. 
You will need to modify boolean IS_-SINK_NODE in source file 
onehopmac .h to program either nodes or sink. 


e Program only one board for the whole network using project 
txrx_wsn_sink, the others using project txrx_wsn_node. 

e Use PuTTY to read from the sink node and switch on the other motes. 

e entercommand cat /dev/comx | ./txrx_wsn.py on the 
computer hosting the sink node. You should see a graph similar to the 
one below. 
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An example outputted graph with 12 
nodes. Links interconnect neighbors; 
colors indicate link quality in dBm. 


e You may move nodes away from each other to obtain a multi-hop 
graph. 


